Google Cloud SQL のリードレプリカで高可用性を有効にできます
ウィスキー、シガー、パイプをこよなく愛する大栗です。
Google Cloud のリリースノートに Cloud SQL のリードレプリカで高可用性を有効にできるようになったという内容が出ていたので検証してみました。
リードレプリカの高可用性構成
今まではリードレプリカがシングルゾーンであったため、障害があった場合に冗長性を確保するためには複数台のリードレプリカを用意してクライアント側でアクセス先を振り替える必要がありました。また、リードレプリカをプライマリインスタンスへ昇格させるときには、今までは昇格させた後に高可用性の有効化を行っていました。そのため昇格後に短期間ですが冗長性が低い状態で運用しており安全性が失われている期間があったり、別途の操作が必要になっていました。
今回のアップデートにより、プライマリインスタンスだけでなくリードレプリカも冗長性化を図れるようになりました。リードレプリカのスタンバイを別のゾーンに配置してディスクをリージョン永続ディスクにすることで高い可用性を担保する構成になります。そのため、リードレプリカの可用性のためにクライアント側の設定が不要になったり、プライマリへ昇格した後に別途高可用性の有効化を行う必要もなくなります。
また、リードレプリカのフェイルオーバーもプライマリインスタンスと同様に、スタンバイインスタンスへ切り替わってもアクセス先の IP アドレスが変わりません。
対象データベース エンジン
リードレプリカで高可用性を有効にできるデータベース エンジンは以下となります。
- MySQL
- PostgreSQL
対象のバージョンに制限はないようで、MySQL 5.6 や PostgreSQL 9.6 でもリードレプリカの高可用性を有効にできます。
やってみた
リードレプリカの高可用性を有効化してみました。実施は以下の環境がある前提で行っています。
- データベース エンジン：PostgreSQL
- バージョン：14
- ゾーン
- プライマリ：asia-northeast1-a（東京）
- スタンバイ：asia-northeast1-c（東京）
対象のプライマリインスタンスをコンソールで表示しています。ここでレプリカをクリックします。
リードレプリカを作成をクリックします。
ここではリージョンはプライマリと同じ東京を選択しました。「ゾーンの可用性」で複数のゾーン（高可用性）を選択します。そして可用性のために1ゾーンを指定して、プライマリインスタンスと異なるゾーンを選択しましょう。レプリカの作成をクリックして、リードレプリカの作成を開始します。
しばらくすると、リードレプリカの作成が完了します。
リードレプリカの概要を確認すると高可用性（リージョナル）と表示されており、高可用性が有効になっていることが分かります。
psql でリードレプリカにログインします。
$ PGPASSWORD=postgres psql -U postgres -h 10.34.81.16
psql (12.11 (Ubuntu 12.11-0ubuntu0.20.04.1), server 14.2)
WARNING: psql major version 12, server major version 14.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> SELECT NOW();
now
-------------------------------
2022-07-13 04:41:10.810035+00
(1 row)
postgres=>
psql でログインした状態で、リードレプリカをフェイルオーバーします。リードレプリカの概要ページの右上にあるフェイルオーバーをクリックします。
リードレプリカのインスタンス ID を入力して、フェイルオーバーをトリガーをクリックします。
しばらくするとフェイルオーバーが完了します。
ログインしたままの psql でクエリを発行すると 1 回目にserver closed the connection unexpectedlyとエラーメッセージが表示されますが、 2 回目はそのまま正常にアクセスにアクセス可能です。
postgres=> SELECT NOW();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
psql (12.11 (Ubuntu 12.11-0ubuntu0.20.04.1), server 14.2)
WARNING: psql major version 12, server major version 14.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
postgres=> SELECT NOW();
now
-------------------------------
2022-07-13 04:54:31.114289+00
(1 row)
postgres=>
リードレプリカをプロモート（昇格）してみます。リードレプリカの概要ページの右上にあるレプリカをプロモートをクリックします。
リードレプリカのインスタンス ID を入力して、プロモートをクリックします。
高可用性が有効なプライマリにプロモートしています。
フェイルオーバーした時と同様に、ログインしたままの psql でクエリを発行すると 1 回目にserver closed the connection unexpectedlyとエラーメッセージが表示されますが、 2 回目はそのまま正常にアクセスにアクセス可能です。
postgres=>
postgres=> SELECT NOW();
FATAL: terminating connection due to administrator command
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset: Succeeded.
psql (12.11 (Ubuntu 12.11-0ubuntu0.20.04.1), server 14.2)
WARNING: psql major version 12, server major version 14.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
postgres=> SELECT NOW();
now
----------------------------
2022-07-13 05:07:13.814+00
(1 row)
postgres=>
さいごに
リードレプリカを高可用性にすることで Cloud SQL の読み取りワークロードも堅牢に使用できるようになりました。リードレプリカの障害時にプライマリへクエリを向けると負荷が上がり詰まってしまう事があるため、リードレプリカの可用性が重要になるため、利用してみてください。
- 高可用性について リードレプリカでは、リードレプリカをプライマリインスタンスやスタンバイインスタンスを異なるゾーンへ配置するベストプラクティスが記載されています。 ↩
